1. Field of the Invention
This invention relates to asynchronous outbound transactions and more particularly relates to asynchronous outbound transactions to an SAP application using a service oriented architecture.
2. Description of the Related Art
Communication over the Internet and similar computer networks where components and communication pathways have a tendency to change more easily lends itself to loosely coupled connections using service oriented architectures (“SOA”). Loose coupling describes a relationship between two or more computer systems exchanging data where each end of a communication or transaction makes its requirements explicit and makes few assumptions about the other end. Loose coupling lends itself to replaceable components within or at either end of a communication pathway.
SOA is a perspective of software architecture where services are used to support the requirements of software users. Nodes in an SOA environment make resources available to other participants in the network as independent services that a participant may use in a standardized way. Services interoperate based on a formal definition, or contact, which is independent from the underlying platform and programming language. Software components are reusable and replaceable because the interface is standards-compliant and independent of the underlying implementation of the service. SOA can support integration with a complex enterprise information system (“EIS”).
An EIS is a complex computing system that supports a high quality of service, usually dealing with large volumes of data, and is capable of supporting a large organization, such as a banking system or a large retail chain. Examples of enterprise information systems are Oracle®, PeopleSoft®, and SAP®. SAP is a program used for managing business information, customer relations, supply chains, human resources, and product lifecycles, among other services. SAP and other enterprise information systems may exchange information with other enterprise information systems. Integration brokers facilitate information exchange. An example of an integration broker is the WebSphere® Process Server (“WPS”). An integration broker includes an adapter to interface with an enterprise information system, such as SAP, with another enterprise information system or for a client application.
An important form of communication between enterprise information systems is that of a transaction. A transaction involves a related collection of operations. A transaction has the properties of atomicity, consistency, isolation, and durability. Atomicity means that all of the operations are applied or none of them are applied. For example, in a financial transaction, a credit to one account and debit to another account must both be applied or neither applied. Consistency means that the transaction represents a correct transformation of the application state. For example, in a financing, the sum of all asset accounts must equal the sum of all liabilities. Isolation means that the effects of one transaction do not affect other transactions executing concurrently. Durability means that once a transaction successfully completes, changes to the application will survive failures. This is usually accomplished through backing up data and error recovery.
Typically a transaction involving two or more resource applications requires a verification process called a two-phase commit. A two-phase commit involves a first step of sending the required data and accompanying instructions to each resource application for execution. Each resource application executes the required part of the transaction and logs the transaction. Each resource application then typically replies to a resource manager with an agreement message if the transaction succeeded or an abort message. In an asynchronous environment, the agreement message may simply be an acknowledgement that the resource application has successfully received the data for execution. If all the resource applications return a success message, then the resource manager can send a commit message and the resource applications release all locks on the transaction, finalize the changes, and send an acknowledgment to the resource manager. In case of failure of any part of the operation, the resource manager may signal a rollback and all operations are undone and the affected accounts are restored to the state prior to the operation.
Where only one resource application is part of a transaction, a similar procedure may be used to ensure once only delivery of the transaction. Such a transaction may be called a local transaction. A local transaction does not involve a two-phase commit, but may include a commit step after execution of the transaction in the resource application. For one or more resource applications, the resource applications may be running on various enterprise information systems loosely coupled through an integration broker and complying with the SOA. Once only delivery is a method to verify that all parts of a transaction are completed or none at all. For example, if one account is debited and another account is credited in a transaction, once only delivery assures that the debit action and the credit action are processed or neither is processed.
One method for communicating with an SAP application is to use a form of the remote function call (“RFC”) protocol. Transactional RFC (“tRFC”) protocol is used for asynchronous transactions. SAP applications may use the application link enabling (“ALE”) interface or a similar interface for processing asynchronous transactions. Transactions may be inbound or outbound. Outbound transactions with an SAP application are from the perspective of an adapter in communication with the SAP application and cover transactions transmitted to the SAP application from the adapter. Adapters available in the present state of the art for handling outbound asynchronous transactions from an adapter to an SAP application do not support guaranteed once only delivery using J2EE Connector Architecture (“JCA” or “J2C”) calls for local transactions. Adapters in the current state of the art handling outbound asynchronous transactions from an adapter to an SAP application also do not support multiple transactions transmitted to the SAP application at one time.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method for guaranteed delivery for asynchronous J2C outbound transactions to an SAP application using tRFC protocol and the J2C transaction mechanism. Beneficially, such an apparatus, system, and method would convert a service data object comprising at least one business object (“BO”) to an intermediate document (“IDoc”) for delivery to an SAP application.